Semantic Access: Semantic Interface for Querying Databases

Semantic Binary Object-oriented Data Model (Sem-ODM) provides an expressive data model (similar to Object-oriented Data Models) with a well-known declarative query facility SQL (similar to relational databases). Advantages of using Sem-ODM include (i.) friendlier and more intelligent generic user interfaces; (ii.) comprehensive enforcement of integrity constraints; (iii.) greater flexibility; (iv.) substantially shorter application programs; and (v.) easier query facility. SemanticAccess is a set of tools developed to provide a semantic interface to Semantic Binary Object-oriented Databases (Sem-ODB) as well as relational databases. This presentation focuses on the system architecture of SemanticAccess including Semantic Binary Object-oriented Data Model, Semantic SQL query language, Semantic Binary Database and a wrapper developed for relational databases. 1. Purpose Semantic Binary Object-Oriented Data Model (Sem ODM) [4] combines the advantages of relational and object-oriented data models. Sem-ODM provides expressive data modeling capabilities, similar to objectoriented data model, but also has the simplicity of constructs similar to relational data model (which provides only one construct, namely table). Sem-ODM consists of category, which may be inherited and relation, which is a relationship between categories. Detailed discussion on Sem-ODM can be found in [4]. One of the major advantages contributing to relational databases’ success is the standard query language, SQL, which is declarative in nature. Object-Oriented Database (OODB) query languages are usually correlated with an ObjectOriented Programming Language (OOPL) [1] and/or are procedural in nature [3]. We have adapted SQL (SQL-92) for Sem-ODM (called Semantic SQL), thus providing a well-known declarative query language for Sem-ODM. We, at HPDRC [8], have developed a fully functional Semantic Binary Object-Oriented Database System (SemODB). Due to the above-mentioned features, Sem-ODB has many advantages including friendlier and more intelligent generic user interfaces, comprehensive enforcement of integrity constraints, greater flexibility, substantially shorter application programs and easier query facility. We have been able to successfully deploy Sem-ODB for non-traditional applications such as Geographic Information System (GIS) [2] at the NASA Regional Application Center at Florida International Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the VLDB copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Very Large Data Base Endowment. To copy otherwise, or to republish, requires a fee and/or special permission from the Endowment. Proceedings of the 26th International Conference on Very Large Databases, Cairo, Egypt, 2000 University. In order to propagate the advantages of SemODM and its query facilities to access various databases, we have developed SemanticAccess – a set of tools to access both relational and semantic databases, which is the focus of our discussion in this paper. 2. System Architecture SemanticAccess is a set of tools developed for accessing semantic and relational databases using Semantic Binary Object-Oriented Data Model and Semantic SQL query language. It consists of three major components: Query Coordinator, Relational Site and Semantic Site. Figure 1 depicts the overall architecture of the system. • Query Coordinator: This component is responsible for collecting schemas from different databases and dispatching the users’ queries to the appropriate sites. It contains a catalog of schemas stored in a SemODB. This component uses CORBA based architecture for communication and query distribution to other components. • Relational Site: This component (SemWrap [7]) wraps relational databases to provide a Sem-ODB interface. It contains a knowledge base and a reverseengineering tool (KDBTool) for schema translation and storage. The relational schema is loaded into the knowledge base and a corresponding semantic schema is generated. This conversion process is a bottom-up methodology similar to the reverse order of conversion described in [5]. The DBA can create complex semantic schema with the use of KDBTool and Knowledge Base thereafter. We used Sem-ODB as the storage medium of the knowledge base in the relational site. Translator module implements a query translation algorithm from Semantic SQL to relational SQL. Currently, this module is capable of wrapping any commercial relational database system, which has an appropriate ODBC driver. • Semantic Site: This module implements the Semantic Database Engine (Sem-ODB [6]) and Semantic SQL interpreter. Sem-ODB engine is a multi-platform fully functional client-server database system (platforms include Solaris, HPUX, Linux, and various versions of Windows). Clients running on any platform can interact with one or more database servers running on the same or different platforms. Moreover, database files are fully compatible across platforms at binary level. Multiple clients can access server through network protocols such as TCP/IP or NETBIOS while some other clients can run locally as threads within the server process. While the database is suitable for large applications storing terabytes of data, it is also appropriate for small embedded applications because the database engine has very low memory requirements. Its footprint in main memory is about 2 Megabytes including code and auxiliary structures, plus the amount allocated for cache which could be specified by database administrator. A 2 Megabytes cache is enough for a wide class of embedded applications, which means that the database can efficiently run in 4 Megabytes of total memory. The size of the database server executable is about 1Mb. In addition to the SQL-level access provided by Semantic SQL interpreter, the database engine (architecture shown in Figure 2) provides a native C++ and Java API for elementary database access, similar to procedural access in an OODB. This is the API which controls three modules that work closely together. Vocab controls database schema, SetQuery provides functionality for cursors, and Elementary Queries module is the main module which provides the functionality of the elementary database access. It uses several logical data types (and correspondingly named modules) to represent data: Fact Data, Record Data, and Index. Furthermore, data is stored using one of three physical data storage types which are B-Tree, Bit-Scale, and Raw Data. All three go through Memory manager and Cache Manager to access disk files through the file system. Cache Manager module includes version control and concurrency control to provide complete transaction isolation and optimistic concurrency. Binary data can be stored using Parallel Binary Server which can be a part of the system or run as a separate process on a different server. It uses several Disk Servers for physical storage, which can use either an underlying file system or raw disks to store data. This server is capable of storing huge amounts of binary data such as pictures and other multimedia data distributed over a TCP/IP network. SemanticAccess was implemented in C++. The source code for the database engine itself is about 75,000 lines. In addition to that, the source code of SQL server is about 40,000 lines. KDBTool was implemented in VC++ 6.0 with the use of Microsoft Foundation Classes (MFC) for the implementation of graphical user interfaces to interact with the DBA, while the translator module was implemented in C++. The source code of this module is about 45,000 lines. The Query Coordinator was implemented in C++ as well.